用头脑风暴 Skill 做竞品分析与设计决策
你会学到什么
前两节我们掌握了需求分析提示词和源码竞品分析——它们是"输入"：收集信息、提炼特征。但信息收集完了，怎么做决策？
本节介绍一种不同的AI协作方式：头脑风暴（Brainstorming）。它不是给AI一个提示词等答案，而是你和AI持续对话、逐步收敛——从一个模糊的想法出发，经过提问、探索、对比，最终形成清晰的设计方案。我们会用 Claude Code 的 superpowers 插件中的 brainstorming skill 作为实战工具。
为什么"头脑风暴"比"一次提问"更适合做决策
上一节你拿到了五大组件库的对比矩阵。然后呢？很多人会这样做：
"基于以下竞品分析，帮我选一个技术路线：
Vue组件库 vs Web Components vs Headless UI，
我的项目是..."
text
这叫"一次提问"模式——把所有信息丢给AI，让它帮你拍板。问题在于：
| 一次提问 | 头脑风暴 |
|---|---|
| 你把决策权交给AI | 你保留决策权，AI帮你理清思路 |
| 输出的是AI的结论 | 输出的是你自己想清楚的结论 |
| 无法追问"为什么" | 每一步都可以追问和质疑 |
| 适合简单、明确的任务 | 适合复杂、不确定的决策 |
竞品分析的目的是"做出好决策"，不是"让AI帮你选"。头脑风暴模式的价值在于：AI不是替你做决策，而是像一个经验丰富的同事，通过提问帮你发现自己没想清楚的地方。
头脑风暴 Skill 是什么
superpowers（github.com/obra/superpowers）作者是 Jesse Vincent（Prime Radiant 团队），MIT 协议，截至2026-11-07 GitHub 已超过31万 star 且仍在持续上涨（2026-11-07 核实为 31.4万），是当前最热的编码Agent技能框架。它不止适配 Claude Code——同一个仓库还为 Codex、Cursor、Gemini CLI、GitHub Copilot CLI、OpenCode 等十余种编码Agent提供安装入口。brainstorming 是其中最核心的 Skill。
安装方式
# 方式一：Anthropic 官方插件市场（推荐）
/plugin install superpowers@claude-plugins-official
# 方式二：作者自己的市场（含更多周边插件）
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
bash
安装后 reload 一下，输入 /brainstorming 启动（命令列表里会显示 superpowers 前缀）。官方仓库在 Claude Code 插件市场里默认可见，空格选中、回车安装即可。
中文增强版：superpowers-zh
国内开发者还有更好的选择——superpowers-zh（GitHub: jnMetaCode/superpowers-zh，npm 包同名）：
npx superpowers-zh
bash
它在完整汉化上游14个 skills 的基础上新增4个面向中国开发者的原创 skills，一条命令自动检测你项目里使用的工具并把 skills 装到正确位置，支持 Claude Code、Cursor、Copilot CLI、Gemini CLI 等20余款AI编程工具；代码提交规范、审查风格、中英文混排排版规则都做了中文适配（讲者还提到其搜索与对接范围覆盖 GitHub 之外的国内托管平台，具体能力以仓库 README 为准）。
用多少、用什么
superpowers 是一整套开发方法论，基本工作流是：brainstorming → using-git-worktrees → writing-plans → subagent-driven-development（或 executing-plans）→ test-driven-development → requesting-code-review → finishing-a-development-branch。不必全盘照收，结合前面章节各取所长：
- 头脑风暴（brainstorming）：本节主角，值得长期挂着
- 文档生成类skills：第6、7章已经讲得更细（/docx、/doc-coauthoring、超长文档策略），无需重复使用
- writing-plans / executing-plans：可用 claude-mem 的 make-plan + do 替代（第5章03节）
- 代码提交与审查：用 rules + 自定义 skill 沉淀你自己公司的工作流更合适
它和普通对话有什么不同
普通对话是随意的——你问什么，AI答什么。头脑风暴 Skill 强制执行一个结构化流程（架构级任务的完整链路）：
这个流程的关键约束：
- 一次只问一个问题——不会用一堆问题把你淹没
- 先理解再建议——AI先搞清楚你的约束和目标，再给方案
- 必须你批准才推进——每一步都要你确认，不会跳过你的决策
- 最终产出设计文档——不是聊天记录，是可执行的设计规范
- 写完spec先自审再交人审——检查占位符、前后矛盾、歧义和范围，用户批准后才进入实施计划
新版本补充：先给请求"称重"，再决定流程重量
当前版本的 brainstorming skill 开场会先对请求分类并大声说出来（"这看起来是个边界清晰的小改动，我就在对话里给个短设计，不写spec了"），让你有机会纠正。拿不准时一律往重的走，中途发现隐藏复杂度也会立即升级，绝不降级：
| 路径 | 适用 | 产出 |
|---|---|---|
| Spike | 可行性问题（"能不能/行不行，快速验证就行"） | 一个答案/建议，代码标记为一次性 |
| Bounded | 已有代码库里边界清晰的小改动（新开关、小接口、单文件修复） | 对话里的短设计（几句话到几段话），批准后才动手 |
| Architectural | 新项目、新子系统、改动组件拼装方式或他人依赖的接口 | 完整流程：提问→方案→分段设计→书面spec→writing-plans |
它还设了 HARD-GATE（硬门禁）：设计获批之前禁止任何实现动作——写产品代码、搭脚手架、装依赖、建外部项目都不行。"批准了这个想法"不等于"批准了写代码"；对spec点头也只允许进入写计划，不允许直接开写。
实战：用头脑风暴敲定AI组件库方案
以下是一次真实运行的完整记录：在装有搜索技能的调研目录里启动 /brainstorming，把问题直接抛给它——"基于你对前端UI组件库的了解，我想做一个AI组件库，技术栈及技术方案上如何来做？"
Step 1：澄清问题方向
AI的第一件事不是给方案，而是先确认"AI组件库"这个词到底指什么：
AI: 你说的AI组件库具体是哪种方向？
A. 聊天型——对话界面组件为主
B. 增强通用型——给传统组件加AI能力
C. AI Agent交互——工具调用、过程展示
D. AI Copilot嵌入式——表单/编辑器内嵌助手
text
选A。随后AI公布了它的工作流程：探索上下文 → 提出澄清问题 → 提出2-3个技术方案 → 展示设计方案 → 编写设计文档。它一边引导一边会在选项里给出当前技术前沿的信息（比如标注哪个是主流做法、哪个标注"推荐"并附说明），不只是被动提问。它也会读取当前项目目录——CLAUDE.md、已有的调研文档、你准备的项目代码——不是从零开始。这正是第3章讲的 CLAUDE.md 持久上下文在实战中的应用。
Step 2：逐个追问约束
一次一个问题，帮你把模糊想法磨清楚：
- 目标用户：内部使用 / 开源组件库 / 商业化产品？——答"前期开源、后期商业化"（选项之外的自定义回答完全可以，AI照样接得住）
- 前端框架：基于哪个框架做？——Vue 3 + TS（说"Vue和React都要"也没关系，先选一个，之后让AI照着重写另一套即可）
- 功能模块（出现方括号即多选）：基础聊天 / 富文本渲染 / 多模态 / Agent交互组件——全部勾选
- 后端对接：组件库如何对接AI后端？——答"必须后端无关，不能锁死"。AI顺势确认主流做法是加一层模型 Provider 抽象，并标注推荐
Step 3：三选一，带权衡的方案
澄清四五个问题后，AI给出三套方案，每套都附优劣分析：
- 方案A：Provider抽象层（推荐）——用户代码 → 组件层 → 抽象适配层；内置适配器开箱即用，用户也可以像写插槽一样自定义实现
- 方案B：Harness组件/UI预设——功能全部内置写好，用户安装不同的部分组合使用
- 方案C：同样附完整优劣对比
选A。注意：AI给了推荐，但没有替你做决定——它列出每个方案的优劣和推荐理由，最终选择权在你。顺带一提，方案A正是本课程项目 ai-chat-ui 最终落地的 ChatAdapter 设计（第10章01节会动手实现它）——一次头脑风暴直接对齐了课程主线。
Step 4：输出设计文档
追加一句"把最终讨论的方案文档输出到当前目录，MD格式"，得到一份包含项目定位、功能模块、架构方案、monorepo包结构、扩展性、组件API的完整设计文档，细致程度远超预期。原先一个团队要讨论好几天的事，在多轮问答内收敛完成。
头脑风暴的可视化伴侣
superpowers 的 brainstorming skill 还有一个独特的功能：可视化伴侣（Visual Companion）。当讨论涉及视觉内容时，它可以在浏览器中展示对比图、架构图和方案选项。
什么时候用浏览器，什么时候用终端
| 用终端（文字） | 用浏览器（可视化） |
|---|---|
| 需求和范围问题 | 布局对比、线框图 |
| 概念性的A/B/C选择 | 架构图、流程图 |
| 利弊权衡列表 | 两种设计方案的视觉对比 |
| 技术决策 | 主题配色、间距等视觉参数 |
竞品分析中的可视化场景
竞品分析中有几个特别适合可视化的场景：
- 组件API对比：同一个Button组件，不同库的API差异用代码高亮展示
- 目录结构对比：Element Plus vs Shadcn-Vue 的目录树并排展示
- 设计风格对比：各组件库的默认主题风格可视化
- 技术架构图：Vue路线 vs Headless UI路线的架构差异
可视化伴侣的运作方式：
1. AI 启动本地可视化服务器（一个简单的 HTTP 服务）
2. 把对比内容写成 HTML 文件推送到浏览器
3. 你在浏览器中看到并排对比，点击选择偏好
4. AI 读取你的选择，继续推进对话
text
这个过程不需要你写任何HTML——AI自动生成所有可视化内容，你只需要在浏览器中点击和评价。
当前版本的设计更克制，两个细节值得学：
- 不 upfront 打开，just-in-time 征求：伴侣不会一开始就启动。直到某个问题"看图比读字更清楚"时，AI才单独发一条消息征求同意（它也会如实提示"这功能较新、比较耗token"）；你同意才以
--open启动并自动打开浏览器，拒绝就继续纯文字，不会反复纠缠 - 逐问题判断，浏览器不是默认：即便接受了伴侣，每个问题仍单独判断——布局对比、线框图、架构图、并排视觉设计走浏览器；需求澄清、概念选择、利弊权衡、A/B/C文字选项留在终端。"话题跟UI有关"不等于"这个问题该用浏览器"
头脑风暴 Skill 的核心原则
不管是否使用 superpowers 插件，这些原则适用于任何AI头脑风暴场景：
1. 一次只问一个问题
不要一次抛出五个问题。人的注意力有限，一次回答一个问题的质量远高于一次回答五个。
// 差的做法
"请回答以下问题：1. 目标用户是谁？2. 技术栈是什么？3. 预算多少？4. 时间线？5. 团队规模？"
// 好的做法
"这个组件库的首要目标用户是谁？"
（等回答后，再问下一个）
text
2. 先理解再建议
不要在还没搞清楚约束的情况下就开始给方案。竞品分析中最常见的错误是"看了三个库就急着选一个"——先搞清楚你要解决什么问题，再去看哪个库更合适。
3. 永远给2-3个选项
不要只给一个"最佳答案"。不同的选择有不同的权衡，给选项让决策者自己判断。每个选项都要说明：
- 适用什么场景
- 最大的优势
- 最大的风险
4. YAGNI：不要过度设计
头脑风暴容易"想太多"。YAGNI原则（You Aren't Gonna Need It）提醒我们：不要为了假设的未来需求增加当前的复杂度。
竞品分析中常见的过度设计：
- "也许以后要支持React" → 现在就做框架无关架构
- "也许要支持国际化" → 一开始就设计i18n系统
- "也许要做设计系统" → 第一版就抽象所有Token
这些"也许"大部分永远不会发生，但它们带来的架构复杂度从第一天就开始累积。
5. 分段验证，逐步推进
不要一口气输出完整方案。每推进一段就停下来确认，避免方向跑偏后发现要全部推翻重来。
头脑风暴在竞品分析中的三个应用场景
场景一：从模糊想法到明确需求
"我想做一个AI组件库"这个想法太模糊了。通过头脑风暴：
你: 我想做一个有AI特色的组件库
AI: "AI特色"具体指什么？
A. 组件本身有智能行为（如智能推荐、自动补全）
B. 用AI辅助组件的开发过程（如AI生成组件代码）
C. 组件内置AI能力接口（如对接大模型的对话组件）
你: A和C
AI: 好，你说的"智能行为"，能给一个具体的使用场景吗？
你: 比如表单组件能根据用户输入自动建议校验规则
AI: 明白了。那这个能力是组件内置的，还是需要对接外部AI服务？
...
text
通过多轮提问，"AI组件库"从四个字变成了一份可执行的功能清单。
场景二：从竞品分析到差异化定位
02节我们得到了五大组件库的特性对比。但"差异化"不是看别人没做什么就做什么——而是找到"有真实需求且别人做得不够好"的切入点。
你: 五大组件库都没有AI能力，这是我们的差异化机会吗？
AI: 不一定是。先问几个问题：
1. 用户真的需要组件内置AI吗？还是他们更愿意自己对接？
2. AI能力放在组件层 vs 工具层，哪个对用户价值更大？
3. 有没有竞品在组件层做过AI集成？失败的原因是什么？
我建议先搜索一下社区对这个问题的讨论。
text
AI帮你从"拍脑袋差异"转向"有数据支撑的差异"。
场景三：从技术选型到架构设计
选定了技术路线后，头脑风暴可以继续推进到架构层面：
AI: 确认走Vue 3原生路线。接下来讨论组件的API风格。
你倾向于哪种？
A. Element Plus风格：Props驱动，大量配置项
B. Naive UI风格：TS优先，类型推导优化IDE体验
C. Shadcn-Vue风格：Headless核心 + 样式层分离
考虑到教学目的，我倾向A或B，因为C的认知门槛较高。
text
注意AI的建议基于你的具体约束（教学目的），不是泛泛而谈。
用AI实现"魔鬼代言人"
头脑风暴的一个进阶用法：让AI主动挑战你的想法，而不是一味赞同。
提示词模板
你现在扮演"魔鬼代言人"角色。我会提出一个技术决策，
你的任务是找出这个决策中最大的三个风险，
并为每个风险提供应对方案。
我的决策是：[具体决策]
请按以下格式输出：
1. 风险描述（具体场景，不要模糊）
2. 发生概率（高/中/低）和影响程度（严重/中等/轻微）
3. 应对方案
text
竞品分析中的实战示例
我的决策：选择Vue 3原生组件库路线，不做框架无关设计
AI扮演魔鬼代言人：
1. 风险：如果未来Vue 4 breaking change，组件库需要大规模重构
- 概率：中（Vue从2到3已经有过一次）
- 影响：严重（所有组件的响应式代码可能要改）
- 应对：组件逻辑层用组合式函数封装，视图层薄化，
降低迁移成本
2. 风险：企业客户要求React版本
- 概率：中（企业级项目经常有多框架需求）
- 影响：中等（需要额外投入开发React版本）
- 应对：第一期不做，但API设计参考Headless UI模式，
为未来迁移留空间
3. 风险：与Shadcn-Vue定位重叠，缺乏差异化
- 概率：高（Shadcn-Vue已有10k+ Stars，2026-10）
- 影响：严重（没有差异化就没有用户）
- 应对：核心差异化放在AI能力上（智能表单、上下文感知组件），
而不是在基础组件层面和Shadcn-Vue竞争
text
这个"魔鬼代言人"技巧的价值在于：主动找风险比出了问题再补救好得多。而且AI扮演这个角色时不会有心理负担——它不会因为怕得罪你而回避真问题。
从头脑风暴到设计文档
头脑风暴的最终产出不是聊天记录，而是一份结构化的设计文档。superpowers 的 brainstorming skill 在你确认设计后，会自动把结论写成 docs/superpowers/specs/YYYY-MM-DD-topic-design.md，提交进 git，然后先自审一遍（扫占位符、前后矛盾、歧义表述、范围是否过大），再请你审阅——你批准后它才调用 writing-plans 进入实施计划。
设计文档的核心结构
# AI增强Vue3组件库 - 技术路线设计
## 背景
基于五大组件库竞品分析（02节），经过头脑风暴决策流程。
## 决策
- 技术路线：Vue 3 原生组件库
- API风格：TS优先，Props驱动
- 构建工具：Vite + pnpm Monorepo
- 样式方案：CSS Variables + Design Token
## 决策依据
1. 教学优先，Vue SFC降低学员认知负荷
2. 02节分析显示Vue路线生态成熟度最高
3. AI差异化能力放在组件层，不与Shadcn-Vue正面竞争
## 风险与应对
- Vue 4 兼容风险 → 组合式函数封装逻辑层
- React版本需求 → API设计预留Headless空间
- 差异化不足 → 聚焦AI特色组件
## 后续行动
- 第9章：基础组件开发
- API设计规范：参考Naive UI的TS推导体验
markdown
这份文档就是你接下来开发的指南针——所有的技术细节后面可能变，但方向和理由写清楚了。
把头脑风暴沉淀进全局规则
superpowers 最大的启发不是这个插件本身，而是一个认知：很多时候AI并不清楚你想要什么。与其每次靠插件补救，不如把这套交互习惯写进全局 CLAUDE.md（或所用AI工具的全局配置），让"指令不明确 → 先头脑风暴"成为AI的默认行为——不管是你写代码、输出文档，还是让它做复杂功能，输出质量都会明显提升：
# 需求不明确时的处理规则
当我给你的指令不明确、上下文不全或目标模糊时：
1. 禁止直接猜测，禁止给出万金油式的泛泛方案
2. 一次只问一个问题，理解我真正的需求和约束
3. 每个问题给出2-3个带权衡的选项（含推荐及理由），允许我在选项外自定义
4. 需求收敛、我明确批准后，再输出文档或动手实现
markdown
文末的"头脑风暴Rules"是完整版。不必照抄全文——可以直接让AI帮你把它压缩成上面这样的精简版再放进 CLAUDE.md，关键是把"选项A/B/C + 确认后推进"的交互模板写清楚。这既是借鉴 brainstorming skill 的精髓，也是把外界工具内化成自己的AI生产力方法：一方面用好现成工具，另一方面从工具里提炼符合自己习惯的使用方式。
头脑风暴Rules
# Role & Core Mission
你是一个极其严谨、遵循系统工程方法论的顶尖架构师与全栈开发专家。你的核心任务是协助用户进行云原生基础设施、系统架构或组件设计，并最终输出高质量、生产可用的设计文档。
# Four Constraints (核心四大约束)
在与用户的整个交互过程中，你必须绝对遵守以下四个黄金法则：
1. 单次单问
严格禁止一次性抛出一堆问题轰炸用户。每次交互原则上只提出一个最核心的问题，最多不得超过两个。
2. 先理解再建议
在没有彻底搞清楚用户的约束条件（技术栈、硬件限制、业务场景）和最终目标之前，绝不盲目给出最终方案。
3. 显式确认推进
流程的每一个关键节点和设计步骤，必须获得用户的明确批准（如 同意、继续）后才能推进行动，严禁擅自跳过用户的决策。
4. 最终产出文档
你的最终交付物必须是一份结构化、可执行、符合顶级科技公司标准的设计规范文档（Markdown 格式），而非零散的聊天记录。
# Handling Unclear Requirements & Context (模糊需求与缺省上下文处理机制)
当用户给出的指令不清晰、上下文不全或目标模糊时，你应当化被动为主动，按照以下逻辑引导用户：
- 禁止行为：禁止直接拒绝回答，禁止完全主观地凭空瞎猜，禁止给出过于宽泛无用的万金油方案。
- 正确行为：结合你作为专家的经验，对可能的技术走向进行合理预测，并为用户提炼出 2-3 个最具代表性的高价值推荐场景或技术路线（Options）供用户选择。
交互模板：
（简要分析当前上下文的缺失点）...
为了帮您更精准地梳理需求，基于常见最佳实践，我为您提供以下几种常见的扩展方向或技术选择：
选项 A (偏向方向1)：[简述特点与适用场景]
选项 B (偏向方向2)：[简述特点与适用场景]
选项 C (自定义)：[提示用户补充特定关键信息]
请问您倾向于哪一种，或者有其他想法？（请选择或补充，我们确认后再进行下一步）
# Execution Pipeline (执行流)
Phase 1: 需求对齐与澄清（当前阶段） -> 通过“单次单问”与“提供选项”持续收敛需求。
Phase 2: 架构架构/方案设计（需用户批准） -> 梳理明确的架构边界与核心逻辑。
Phase 3: 最终文档生成（目标） -> 按照 UI/UX 规范与全栈扩展性标准，输出最终的设计规范。
现在，请等待用户的第一个指令。
text
本节要点
- 头脑风暴不是"问AI要答案"，而是"和AI一起想清楚"。竞品分析后的决策阶段，需要的不是AI的结论，而是帮你发现自己没想清楚的地方。
- 结构化流程是关键：一次只问一个问题、先理解再建议、给选项不给答案、分段验证推进。这些原则适用于任何AI工具，不限于superpowers插件。
- 可视化伴侣让对比更直观：当讨论涉及架构、布局、风格等视觉内容时，浏览器中的并排对比比纯文字描述有效得多——但它按需征求、逐问题判断，不是默认开浏览器。
- "魔鬼代言人"是头脑风暴的进阶武器：让AI主动挑战你的决策，在动手之前找到风险，比出了问题再补救成本小得多。
- 最终产出是设计文档，不是聊天记录：头脑风暴的价值在于帮你把模糊的想法变成清晰的、有据可依的、可执行的设计方案。
- 把交互习惯沉淀进 CLAUDE.md：让"指令不明确 → 一次一问 → 给选项 → 批准后推进"成为AI的默认行为，不依赖具体插件。
↑